Customizing visualization in a navigation application using third-party data

ABSTRACT

An interactive digital map is provided via a user interface of a computing device. A request to obtain travel directions to a destination is received via the user interface. An indication of a ride from a pick-up location to a drop-off location, to traverse at least a portion of the route, is obtained from a third-party provider of a ride service. Visualization information for rendering a visualization of the ride on the digital map also is received from the third-party provider of the ride service. The visualization of the ride on the digital map is generated in accordance with the received visualization information.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a continuation of and claims priority to U.S.application Ser. No. 17/095,432, filed Nov. 11, 2020, entitled“Customizing Visualization in a Navigation Application Using Third-PartyData,” which is a continuation of and claims priority to U.S.application Ser. No. 16/220,876, filed Dec. 14, 2018, entitled“Customizing Visualization in a Navigation Application Using Third-PartyData,” which claims priority to U.S. Provisional Patent Application No.62/599,346, filed Dec. 15, 2017, the disclosures of each of which isincorporated herein by reference in its entirety for all purposes.

FIELD OF THE DISCLOSURE

The present disclosure relates to inter-application communication, andmore particularly, to inter-application communication between a mappingapplication and a ride service application.

BACKGROUND

Today, digital maps of geographic areas are commonly displayed oncomputing devices, such as computers, tablets, and mobile phones viamapping applications, web browsers, etc. Many mapping applicationsprovide the user with the ability to select the type of map informationor features for viewing as well as to adjust the display of the digitalmap.

Additionally, mapping application providers offer applicationprogramming interfaces (APIs) for accessing map and navigation data todisplay digital maps and provide step-by-step navigation directions to adestination location. For example, a ride service application may invokea mapping application API to provide a digital map of a geographic areathat includes a pick-up location for the user, a destination location,navigation directions for travelling to the destination location, etc.

SUMMARY

To provide ride services within a mapping application without directingthe user to a separate ride service application, the mapping applicationinvokes one or several ride service APIs to access ride service datafrom various ride service providers. For example, a user may requestnavigation directions within the mapping application to a destinationlocation. The user may then select from several modes of transportationfor travelling to the destination location, including a ride servicemode. When the user selects the ride service mode, the mappingapplication may communicate with various ride service applications byinvoking respective ride service APIs. The mapping applicationcommunicates with the ride service applications and/or ride serviceservers to retrieve indications of the types of ride services providedby each of the ride service providers. Types of ride services mayinclude a carpooling ride service, where the ride service providerspicks up additional passengers on the way to the user's destination, ataxi service that does not pick up additional passengers on the way touser's destination, a limo service that includes additional featureswithin the vehicle, an extra-large vehicle service for picking up largegroups of passengers, etc. The mapping application may also communicatewith the ride service applications to retrieve price estimates for eachtype of ride service, wait times for each type of ride service, ridedurations for each type of ride service, ride status informationregarding the status of trip (e.g., waiting for the driver to accept theride, waiting for the driver to arrive at the pick-up location, ride inprogress, ride completed), a number of vehicles within a geographic areasurrounding the user's current location, etc. In some scenarios, rideservice applications do not need to be downloaded to the user's clientdevice and instead the mapping application invokes the respective rideservice APIs to communicate with ride service servers.

The user may then select a ride service provider and type of rideservice directly from the mapping application to order transportationservices to her destination location. In this manner, a user may selectfrom several candidate ride service providers within the mappingapplication without having to open each of the corresponding rideservice applications for comparison and without leaving the mappingapplication. Moreover, a user may identify pick-up locations anddestination locations in an application that has built-in mapfunctionality. For example, the user may view a three-dimensional streetlevel view of the area around the pick-up location, so that the user mayeasily find the driver at the pick-up location. The mapping applicationmay also provide recommendations on pick-up locations based on thecontext and location of the user as well as walking directions from theuser's current location to the pick-up location.

In particular, an example embodiment of the techniques of the presentdisclosure is a method in a computing device for providing multi-modaltravel directions. The method includes receiving, via a user interface,a request to obtain travel directions to a destination and generatingmulti-modal travel directions for traveling to the destination.Generating the multi-modal travel directions includes obtaining, from athird-party provider of a ride service, an indication of a ride totraverse a first segment of the route between a pick-up location and adrop-off location, the ride service defining a first mode of transport,and obtaining navigation directions to traverse a second segment of theroute using a second mode of transport different from the first mode.The method further includes providing an indication of the generatedmulti-modal directions via the user interface.

Another example embodiment is a computing device including a userinterface, one or more processors, and a non-transitory computerreadable medium storing instructions thereon. When executed by the oneor more processors, the instructions cause the computing device toreceive, via the user interface, a request to obtain travel directionsto a destination, and generate multi-modal travel directions fortraveling to the destination. To generate the multi-modal traveldirections, the instructions cause the computing device to obtain, froma third-party provider of a ride service, an indication of a ride totraverse a first segment of the route between a pick-up location and adrop-off location, the ride service defining a first mode of transportand obtain navigation directions to traverse a second segment of theroute using a second mode of transport different from the first mode.The instructions further cause the computing device to provide anindication of the generated multi-modal directions via the userinterface.

Yet another example embodiment is a method in a computing device forproviding multi-modal travel directions. The method includes providingan interactive digital map via a user interface, receiving, via the userinterface, a request to obtain travel directions to a destination, andobtaining, from a third-party provider of a ride service, an indicationof a ride from a pick-up location to a drop-off location to traverse atleast a portion of the route. The method further includes receiving,from the third-party provider of the ride service, visualizationinformation for rendering a visualization of the ride on the digitalmap, and generating the visualization of the ride on the digital map inaccordance with the received visualization information.

Another example embodiment is computing device including a userinterface, one or more processors, and a non-transitory computerreadable medium storing instructions thereon. When executed by the oneor more processors, the instructions cause the computing device toprovide an interactive digital map via a user interface, receive, viathe user interface, a request to obtain travel directions to adestination, and obtain, from a third-party provider of a ride service,an indication of a ride from a pick-up location to a drop-off locationto traverse at least a portion of the route. The instructions furthercause the computing device to receive, from the third-party provider ofthe ride service, visualization information for rendering avisualization of the ride on the digital map, and generate thevisualization of the ride on the digital map in accordance with thereceived visualization information.

Another example embodiment is a method in a portable computing devicefor providing ride service information a digital map. The methodincludes providing, via a user interface, an interactive digital map ofa geographic area, receiving, via the user interface, a request toobtain travel directions to a destination, and requesting from aplurality of third-party providers of ride services, respectiveindications of candidate rides for at least a portion of a route to thedestination, each of the indications including a pick-up location, aprice estimate, and pick-up time. The method further includes, receivingthe requested indications of the candidate rides, determining a rankingthe candidate rides according to at least one of price and pick-up time,providing, on the digital map, a listing of the candidate rides inaccordance with the determined ranking, and in response to one of thecandidate rides being selected via the user interface, transmitting arequest for the selected ride to the corresponding third-party provider.

Yet another example embodiment is a method in a portable computingdevice for providing map data related to a ride service on a computingdevice. The method includes providing an interactive two-dimensionaldigital map via a user interface, receiving, via the user interface, arequest to obtain travel directions to a destination, and obtaining froma third-party provider of a ride service, an indication of a ride from apick-up location to a drop-off location to traverse at least a portionof the route. The method further includes obtaining street-level imageryfor the pick-up location, displaying the obtained street-level imageryfor the pick-up location on the digital map, and in response todetecting a selection of the street-level imagery via the userinterface, transitioning the two-dimensional digital map to aninteractive three-dimensional panoramic display of street-level imagery.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example system in which techniques forproviding ride services via a mapping application to a portable devicecan be implemented;

FIG. 2 is a block diagram of an example portable device that can operatein the system of FIG. 1 ;

FIG. 3 is an exemplary sequence diagram that illustrates an exampleexchange of information between a mapping application and a ride serviceapplication in response to user input provided to the mappingapplication;

FIG. 4 is an exemplary flow diagram for transitioning between userinterfaces during a ride service request within a mapping application;

FIG. 5 is an exemplary state diagram for requesting ride services via amapping application by invoking a ride service API;

FIG. 6 is an exemplary flow diagram for generating recommendedmulti-modal routes from a starting location to a destination location;

FIG. 7 is an exemplary flow diagram for providing ride services within amapping application without directing the user to a separate rideservice application;

FIG. 8 is an exemplary flow diagram for presenting ride statusinformation when the user transitions to other mapping functionality;

FIG. 9 is an exemplary display for selecting a ride service provider ina mapping application;

FIG. 10 is an exemplary display for selecting a pick-up location in amapping application;

FIG. 11A is an exemplary ride request display in a mapping applicationthat includes layout components which are customized by a ride serviceprovider;

FIG. 11B is another exemplary ride request display in a mappingapplication that includes layout components which are customized by aride service provider;

FIG. 12A is an exemplary pick-up request display for confirming a ridein a mapping application;

FIG. 12B is another exemplary pick-up request display for confirming aride in a mapping application;

FIG. 12C is yet another exemplary pick-up request display for confirminga ride in a mapping application;

FIG. 13A is an exemplary wait for ride display presented when the userwaits to be picked up by a ride service provider in a mappingapplication;

FIG. 13B is another exemplary wait for ride display presented in amapping application.

DETAILED DESCRIPTION Overview

Generally speaking, techniques for providing ride services within amapping application can be implemented in a mapping applicationoperating in a portable computing device or a wearable device, one orseveral network servers, or a system that includes a combination ofthese devices. However, for clarity, the examples below focus primarilyon an embodiment in which a user requests ride services via a mappingapplication within a portable computing device. The mapping applicationinvokes one or several ride service APIs to communicate with respectiveride service applications and/or ride service servers. The mappingapplication may also communicate with a map data server and/or anavigation data server to retrieve map and navigation data fordisplaying an interactive two-dimensional digital map of a geographicarea surrounding the user's current location and navigation directionsto a destination location (also referred to herein as a “drop-offlocation”) selected by the user.

The mapping application may then display ride service data for one orseveral ride service providers including the types of ride servicesoffered by each ride service provider, price estimates for each type ofride service, wait times for each type of ride service, ride durationsfor each type of ride service, vehicles within a geographic areasurrounding the user's current location, etc.

When the user selects a ride service provider and type of ride service,the mapping application may prompt the user to select a pick-uplocation. In some embodiments, the mapping application provides adefault pick-up location near the user's current location and the usermay adjust the pick-up location via user controls. Also in someembodiments, the mapping application may provide a recommended pick-uplocation based on the user's current location and context information.For example, in an area with several one-way streets, the mappingapplication may recommend a pick-up location at a street that allowsdrivers to travel in the direction of the destination location, so thatthe driver does not need to make unnecessary turns after picking up theuser. In another example, the recommended pick-up location may bedetermined based on traffic to avoid streets with heavy traffic in orderto minimize cost.

In response to receiving a selection of the pick-up location, themapping application may invoke a ride service API corresponding to theselected ride service provider and provide rider identificationinformation for the user, the requested pick-up location, and the typeof ride service to the corresponding ride service application. The rideservice application may then provide a ride identifier, an updated waittime, updated price estimate, updated ride duration, and driveridentification information for display on the mapping application viathe ride service API. As a result, a driver may pick-up the user at therequested pick-up location and drop the user off at the destinationlocation.

Example Hardware and Software Components

Referring to FIG. 1 , an example communication system 100 in which thetechniques outlined above can be implemented includes a client computingdevice 102, such as a portable device configured to execute one orseveral ride service applications 126 and a mapping application 128. Inaddition to the client computing device 102, the communication system100 includes a server device 104, such as a navigation server deviceconfigured to provide a map display and navigation data to the clientcomputing device 102. The communication system 100 also includes athird-party provider device 106 (which operates independently andseparately from the server device 104) that may be configured tocommunicate with the client computing device 102 and the server device104 for the purposes of providing ride service functionality. The clientcomputing device 102, the server device 104, and the third-partyprovider device 106 may be communicatively connected to each otherthrough a network 108. The network 108 may be a public network, such asthe Internet, or a private network such as an intranet.

The server device 104 can be communicatively coupled to a database 110that stores, in an example implementation, map data for variousgeographic areas. Similarly, the server device 104 can becommunicatively coupled to a database 144 that stores, in an exampleimplementation, vehicle data 144 for various vehicles associated with auser of the client computing device 102, vehicles associated with thethird-party provider 106, other vehicles whose data is collected by theserver device 104, or other servers, or combinations of all three. Moregenerally, the server device 104 can communicate with one or severaldatabases that store any type of suitable geospatial information orinformation that can be linked to a geographic context, such as couponsor offers. The server device 104 can also be communicatively coupled toa database (not shown) that stores, in an example implementation,navigation data including step-by-step navigation directions such asdriving, walking, biking, or public transit directions, for example,that may be ultimately utilized by both the ride service application126, the mapping application 128, or both. For example, the serverdevice 104 may request and receive map data from the map data database110 as well as relevant vehicle data from the vehicle data database 144.In some implementations the server device 104 may include severalcommunicatively connected server devices. Similarly, the map data andthe vehicle data, stored in the databases 110 and 144 respectively, mayin fact be several databases communicatively connected in a clouddatabase configuration.

In an example implementation, the client computing device 102 may be asmart phone or a tablet computer, for example, and includes a memory120, one or more processors 112, a network interface 116, a userinterface (UI) 114 and one or several sensors 118. The memory 120 can bea non-transitory memory and can include one or several suitable memorymodules, such as random access memory (RAM), read-only memory (ROM),flash memory, other types of persistent memory, etc. The UI 114 may be atouch screen, for example. More generally, the techniques of thisdisclosure can be implemented in other types of devices, such as laptopor desktop computers, a device embedded in a vehicle such as a vehiclehead unit, wearable devices, such as smart watches or smart glasses,etc.

Depending on the implementation, the one or more sensors 118 can includea global positioning system (GPS) module to detect the position of theclient computing device 102, a compass to determine the direction of theclient computing device 102, a gyroscope to determine the rotation andtilt, an accelerometer, etc.

The memory 120 stores an operating system (OS) 122, which can be anytype of suitable mobile or general-purpose operating system. The OS 122can include API functions that allow applications (such as the rideservice application 126 and the mapping application 128) to interfacewith each other, or to retrieve, for example, sensor readings. Forexample, a software application configured to execute on the clientcomputing device 102 can include instructions that invoke an OS 122 APIfor retrieving a current location and orientation of the clientcomputing device 102 at that instant. The API can also return aquantitative indication of how certain the API is of the estimate (e.g.,as a percentage).

The memory 120 also stores the mapping application 128, which isconfigured to generate interactive digital maps. The mapping application128 can receive map data in a raster (e.g., bitmap) or non-raster (e.g.,vector graphics) format from the map data database 110 and/or the serverdevice 104. In some cases, the map data can be organized into layers,such as a basic layer depicting roads, streets, natural formations,etc., a traffic layer depicting current traffic conditions, a weatherlayer depicting current weather conditions, a navigation layer depictinga path to reach a destination, etc. The mapping application 128 also candisplay navigation directions from a starting location to a destinationlocation. The navigation directions may include driving, walking, orpublic transit directions.

It is noted that although FIG. 1 illustrates the mapping application 128as a standalone application, the functionality of the mappingapplication 128 also can be provided in the form of an online serviceaccessible via a web browser executing on the client computing device102, as a plug-in or extension for another software applicationexecuting on the client computing device 102, etc. The mappingapplication 128 generally can be provided in different versions fordifferent respective operating systems. For example, the maker of theclient computing device 102 can provide a Software Development Kit (SDK)including the mapping application 128 for the Android™ platform, anotherSDK for the iOS™ platform, etc.

In some implementations, the server device 104 includes one or moreprocessors 130, APIs 132, a network interface 134, and a memory 136. TheAPIs 132 may provide functions for interfacing with applications thatmay be stored in the memory 136 on the server device 104. The memory 136may be tangible, non-transitory memory and may include any types ofsuitable memory modules, including random access memory (RAM), read-onlymemory (ROM), flash memory, other types of persistent memory, etc. Thememory 136 stores instructions executable on the processors 130 whichcan generate map displays to be displayed by the mapping application 128for a geographic area. The memory 136, or the memory in another server,similarly can store instructions that generate navigation directions toa geographic location within the geographic area and which may bedisplayed overlaying the map display by the mapping application 128. Insome implementations, the third-party provider 106 may initiate calls tothe server device 104 for navigations directions that may be used by theride service application 126 on the client computing device 102.

For simplicity, FIG. 1 illustrates the server device 104 as only oneinstance of a server. However, the server device 104 according to someimplementations includes a group of one or more server devices, eachequipped with one or more processors and capable of operatingindependently of the other server devices. Server devices operating insuch a group can process requests from the client computing device 102individually (e.g., based on availability), in a distributed mannerwhere one operation associated with processing a request is performed onone server device while another operation associated with processing thesame request is performed on another server device, or according to anyother suitable technique. For the purposes of this discussion, the term“server device” may refer to an individual server device or to a groupof two or more server devices.

In some implementations, the third-party provider device 106 or rideservice provider device may include processors 138, APIs 140, a networkinterface 142, and a memory 144. The APIs 140 may provide functions forinterfacing with applications that may be stored in the memory 144 onthe third-party provider 106. The memory 144 may be tangible,non-transitory memory and may include any types of suitable memorymodules, including random access memory (RAM), read-only memory (ROM),flash memory, other types of persistent memory, etc. The memory 144stores instructions executable on the processors 138 which can generate,handle, and transmit requests for ride service functions in a rideservice application, such as the ride service application 126 stored inthe memory 120 of the client computing device 102.

In some implementations, the system 100 includes several third-partyprovider devices 106 corresponding to several different ride serviceproviders. Also in some instances, the client computing device 102includes several ride service applications 126 corresponding to each ofthe ride service providers. In this manner, a user may compare rideservice types, price estimates, ride durations, and estimated wait timesfor several ride service providers.

FIG. 2 is a block diagram of an example software architecture 200 whichmay be implemented on the client computing device 102, and may includeprotocols for communicating between the operating system 122, the rideservice application 126, the mapping application 128, services 202 onthe client computing device, as well as other applications 204. In someimplementations, the ride service application exposes a ride service API206 that is invoked by the mapping application 128. In this manner, themapping application 128 may allow users to request ride services withouthaving to leave the mapping application 128. For example, the mappingapplication 128 may provide pick-up and destination locations to theride service API 206, which may in turn provide the types of rideservices in the geographic area, price estimates for each type of rideservice, wait times for each type of ride service, ride durations foreach type of ride service, a number of vehicles within the geographicarea, etc.

In general, the mapping application 128 may make function calls to theride service application 126 or a ride service server 106 by accessingthe ride service API 206. The API 206 facilitates inter-applicationcommunication and allows the mapping application 128 and ride serviceapplication 126 to maintain control over how processes, logic, and usersare handled while still exposing functionality to other applications.The applications 126 and 128 can communicate using an inter-processcommunication (IPC) scheme provided by the operating system 122. In someembodiments of the client computing device 102, the functionality of theride service application 126 can be provided as a static library offunctions accessible via the ride service API 208. In other words, someor all of functions of the ride service application 126 can execute aspart of the mapping application 128. More generally, the ride serviceAPI 208 provides, to the mapping application 128, access to a rideservice using any suitable software architecture and communicationschemes, including those currently known in the art. The ride serviceAPI 208 generally can be provided in different versions for differentrespective operating systems. For example, the maker of the clientcomputing device 102 can provide a Software Development Kit (SDK)including the ride service API 208 for the Android™ platform, anotherSDK for the iOS™ platform, etc.

In some instances, the mapping application 128 may communicate withseveral ride service applications via respective APIs. If the user doesnot have a ride service application that the mapping application 128communicates with, the user may be prompted to download the ride serviceapplication 126. In other embodiments, the user does not download theride service application 126 and the mapping application 128 maycommunicate with a ride service server, such as the third-party providerdevice 106 as shown in FIG. 1 , via the ride service API 206.

FIG. 3 is an exemplary sequence diagram 300 depicting calls between amapping application and a ride service application utilizing APIs. Thesequence diagram 300 illustrates an example message sequence chart forone implementation of the embodiments disclosed herein. The sequencediagram 300 includes a user 302, a mapping application 128, a rideservice application 126, and a ride service API 208.

In the example sequence diagram 300, the user 302 requests ride services304 via user controls on a display presented by the mapping application128. For example, the user may request directions to a selecteddestination location for a ride services mode of transportation. Inresponse to the request, the mapping application 128 may generate an APIcall for ride services to the ride service application API 208, wherethe API call includes a request for ride services along with the currentlocation of the user and the destination location 306, for example. TheAPI call is then sent as a request 308 to a ride service application 126or a ride service server, such as the third-party provider device 106.

The ride service application 126 may perform its own internal functionsto determine the types of ride services available to service the user302, price estimates for transporting the user 302 to the destinationlocation, wait times for picking up the user 302, a number of vehicleswithin a geographic area surrounding the user's current location, etc.The ride service application 126 then prepares a response 310 to be sentto the mapping application 128 with, for example, types of ride servicesavailable, an estimated time for arrival of a ride through each type ofride service, an estimated price for each type of ride service, anestimation of the vehicles/drivers in the area, or combinations thereof.The response 310 is received by the ride service API 208 and thenformatted and provided to the mapping application 128 (ref. no. 311)where it is handled, and manipulated if necessary, into for display 312to the user 302.

For example, the mapping application 128 may display indications of eachtype of ride service available (e.g., a carpooling ride service, a taxiride service, a limo ride service, an extra-large vehicle service), aprice estimate for each type of ride service, a ride duration for eachtype of ride service, and an estimated wait time for each type of rideservice. The mapping application 128 may also display indications ofvehicles on the map display in proportion to the number of vehicleswithin the geographic area, as indicated by the ride service API 126.While the locations of the vehicles on the map display may not be anaccurate representation of the locations of the vehicles employed by theride service provider, the number of vehicles on the map display may beused to show the user an approximation of the amount of vehicles in thearea. When multiple ride service providers are available, the mappingapplication 128 may display the indications of vehicles employed by eachride service provider in a different style or color.

In some embodiments, the displayed indications of available types ofride services may include selectable user controls for selecting a typeof ride service. The user 302 views the displayed indications 312 andselects a type of ride service. The mapping application 128 may thenpresent a user control for selecting a pick-up location. The usercontrol may be a pin placed at the user's current location or a nearbythe user's current location and the user may be able to move the pin toanother location, by entering an address or point of interest (POI),dragging the pin to another location, or in any other suitable manner.The pick-up location and selected type of ride service are then providedto the ride service API 208 (ref. no. 316) and forwarded to the rideservice application 126 (ref. no. 318). The ride service application 126then selects a driver for picking up and the user and transmits driveridentification information for the selected driver (e.g., the name ofthe driver, the vehicle make, model, and color, a license plate number,etc.), an updated price estimate, an updated wait time, a ride ID forretrieving status information indicating that the driver is on the wayto pick-up the user, etc. to the ride service API 208 (ref. no. 320)which is then formatted and provided to the mapping application 128(ref. no. 321). Accordingly, the mapping application 128 may present anindication of the status of the driver (e.g., on the way to pick-up theuser), the updated price estimate, the updated wait time, and the driveridentification information to the user 302.

FIG. 4 illustrates an exemplary flow diagram 500 for transitioningbetween user interfaces during a ride service request within a mappingapplication 128. The method may be implemented in a set of instructionsstored on a computer-readable memory and executable on one or moreprocessors of the client computing device 102. For example, the methodcan be implemented by the mapping application 128, the ride serviceapplication 128, or any suitable combination of these.

At block 502, a map display is presented that includes a geographic areasurrounding the user's current location. An indication of the user'scurrent location may also be presented on the map display. Then at block504, the mapping application 128 presents a search bar for obtaining ageographic search query from a user and providing search results inresponse to the geographic search query. For example, the search resultsmay include POIs, addresses, intersections, etc., and the user mayselect one of the search results as a destination location and requestdirections to the selected destination location.

The mapping application 128 may also include user controls for selectingbetween several modes of transportation, including a ride services modeof transportation. In response to receiving a selection of the rideservice mode of transportation, the mapping application 128 may presenta ride request display (block 506) including indications of ride serviceproviders, types of ride services from the ride service providers, priceestimates for each type of ride service, ride durations for each type ofride service, wait times for each type of ride service, etc., similar tothe display as shown in FIG. 11B. In some embodiments, the mappingapplication 128 may invoke a ride service API for each of one or severalride service applications and may provide the user's current locationand destination location to each of the ride service applications viathe respective APIs.

In response to receiving a selection of a ride service provider and/ortype of ride service, the mapping application 128 may present a pick-uprequest display (block 508) that includes a user control for selecting apick-up location, similar to the display as shown in FIG. 12A. Thepick-up request display may include a default pick-up location within athreshold distance of the user's current location (e.g., 500 feet),where the default pick-up location is adjustable by the user. Forexample, the user may enter in the pick-up location or drag a pinpresented at the default pick-up location to select the pick-uplocation. In some embodiments, the mapping application 128 may provide arecommended pick-up location to save time and money. For example, therecommended pick-up location may be 350 feet from the user's currentlocation, and the pick-up request display may indicate that the user can“Save 3 mins and $2” by selecting the recommended pick-up location. Thepick-up request display may also include a user control for confirmingthe pick-up location, such as a “Confirm Pick-up” button after selectingthe pick-up location.

In response to receiving a selection of a pick-up location, the mappingapplication 128 may present a wait for ride display (block 510), similarto the display as shown in FIG. 13A. The wait for ride display mayinclude an indication of the driver's current location, identificationinformation for the driver, an estimated wait time for the driver toarrive at the selected pick-up location, and a user control forcontacting the driver. Once the driver arrives, the user may betransported to the destination location.

When the user requests ride services within the mapping application 128,the mapping application 128 provides user login information to a rideservice provider to login the user to a user profile maintained by theride service provider. For example, the user profile may include paymentmethods for the user, the name of the user, an email address of theuser, a phone number of the user, a picture of the user for the driverto identify the user, a rating of the user, a ride ID for a ridecurrently in progress or ride the user is requesting, or any othersuitable user profile information. Once the user confirms a riderequest, the mapping application 128 may receive a ride ID forretrieving status information for the ride, such as “Waiting for thedriver to accept the ride request,” “Waiting for the driver to arrive atthe pick-up location,” “Ride in progress,” and “Ride completed.”

FIG. 5 is an exemplary state diagram 600 for requesting ride servicesvia the mapping application 128 by invoking the ride service API 208.The state diagram 600 depicts several states, such as an initial state602, a sign-in state 604, a confirm/book state 606, a restore state 608,a ride in progress state 610, and a transition state 612. At any momentany of the states 602-610 may return to the initial state as denoted inthe state diagram 600.

In one implementation, a user opens a mapping application 128 and beginsin the initial state 602. In the initial state 602, the mappingapplication 128 presents a map display of a geographic area and mayreceive geographic search queries, provide search results in response tothe geographic search queries, and display navigation or traveldirections from the user's current location or some other specifiedstarting location to a selected destination location. The navigation ortravel directions may be provided for several different modes oftransportation (e.g., walking, biking, driving, public transit, rideservices, a recommended mode of transportation that may include multiplemodes of transportation for arriving at the destination location basedon the shortest duration, distance, or lowest cost, etc.). When the userselects a ride services mode of transportation or selects multi-modaltravel directions that include a segment covered by a ride service andselects a ride service provider/type of ride service, the mappingapplication 128 proceeds to the sign-in state 604.

In the sign-in state 604, the mapping application 128 determines whetherthe user is signed into a client account 616 associated with a providerof the mapping application 128. If the user is not signed in, themapping application 128 may provide user controls for entering userlogin information, such as a username and password to sign into theclient account 616. When the user signs in, the mapping application 128signs the user into a user profile associated with the third-partyprovider 618 that provides the ride service. In some embodiments, theuser may sign into the third-party provider using the client account 616associated with the provider of the mapping application 128. When theuser is signed into the third-party provider, the mapping application128 invokes the ride service API 208 to retrieve a ride ID associatedwith the user profile to determine whether there is a ride currently inprogress. If there is a ride currently in progress, the mappingapplication 128 transitions to the restore state 608. On the other hand,if there is no ride ID, the mapping application 128 proceeds to theconfirm/book state 606.

In the confirm/book state 606 and more specifically the confirm state620, the mapping application 128 presents a pick-up request display,that includes a user control for selecting a pick-up location, similarto the display as shown in FIG. 12A. The pick-up request display mayalso include user controls for selecting or adding payment methods. Forexample, the mapping application 128 may retrieve payment methods forthe user that are stored with the ride service provider via the rideservice API 208. The mapping application 128 may display maskedindications of each of these payment methods for the user to choose fromand may display an additional user control for the user to enter a newpayment method. In some embodiments, when the user has selected apick-up location and payment method, the mapping application 128 maypresent a user control such as a “Confirm Pick-up” button, which whenselected, transitions the mapping application 128 to the book state 622.

In the book state 622, the mapping application 128 requests rideservices from the ride service provider from the pick-up location to thedestination location via the ride service API 208. The ride service API208 then communicates with the ride service provider to select a driverfor the ride. For example, the ride service provider may broadcast amessage to each of the drivers within a threshold distance of thepick-up location and may select the first driver to respond to thebroadcasted message. In any event, the ride service API 208 may thenprovide a ride ID to the mapping application 128 and the mappingapplication 128 proceeds to the ride in progress state 626. In the ridein progress state, the mapping application 128 continuously orperiodically (e.g., every 5-10 seconds) calls a get ride status function612 to receive status information regarding the status of the ride byproviding the ride ID to the ride service API 208. In response, the rideservice API 208 provides status information to the mapping application128. The status information may include: waiting for the driver toaccept the ride 628, waiting for the driver to arrive at the pick-uplocation 630, ride in progress 632, and ride completed 634.

During the waiting for the driver to arrive at the pick-up location 630and ride in progress 632 states, the ride service API 208 may alsoreturn a current location of the driver for display via the mappingapplication 128. In this manner, the mapping application 128 may presentan indication of the driver on the map display along with the pick-uplocation or destination location for the user to view the driver'sprogress to the pick-up location or on the route to the destinationlocation. Additionally, during the waiting for the driver to accept theride 628, waiting for the driver to arrive at the pick-up location 630,and ride in progress 632 states, the mapping application 128 may presenta user control for cancelling the ride which when selected, may causethe mapping application 128 to provide a cancel request to the rideservice provider via the ride service API 208 to cancel the ride. Themapping application 128 may also present a user control for modifyingthe destination location which when selected, may cause the mappingapplication 128 to provide a modify destination request to the rideservice provider via the ride service API 208.

Once the user is dropped off at the destination location, the mappingapplication 128 proceeds to the completed state 632. In the completedstate 632, the mapping application 128 may present a summary of the rideincluding a final price of the ride, a user control for rating thedriver, or any other suitable information regarding the rate. Then themapping application 128 may return to the initial state 602.

As mentioned above, the mapping application 128 transitions to therestore state 608 when the user signs into the third-party provider andthere is a ride currently in progress. For example, the user may haveexited the mapping application 128 and then reopened it while requestinga ride. In the restore state 608, the mapping application 128 proceedsto the ride in progress state 626 and continuously or periodically(e.g., every 5-10 seconds) calls a get ride status function 612 toreceive status information regarding the status of the ride.

In addition to providing ride services, the mapping application 128provides multi-modal modes of transportation for navigating a user toher destination location. For example, the user may select a recommendedmode of transportation that may include multiple modes of transportationfor providing an optimal route to the destination location based on theshortest duration, distance, lowest cost, etc. In some embodiments, theuser may provide preferences, such as “Avoid highways,” “Utilize publictransit,” “Avoid walking directions at night,” “Lowest cost,” “Shortestduration,” may indicate a preferred mode of transportation, a preferredride service provider, and/or preferred ride service type (e.g., acarpooling ride service), or may provide any other suitable preferences.Accordingly, the mapping application 128 may present one or severaloptimal routes to the destination location using one or several modes oftransportation and according to the user's preferences.

In some embodiments, the mapping application 128 provides a request fornavigation directions using a recommended mode of transportation to theserver device 104 including a starting location, a destination location,and user data including the user's preferences. The server device 104may retrieve map data, navigation data, traffic data, etc. to generateroutes from the starting location to the destination location. Also insome embodiments, the server device 104 may invoke ride service APIs 208to retrieve ride service data for ride service providers, such asestimated wait times and price estimates for particular segments of theroute. For example, an optimal route may include a ride service toand/or from a public transit stop. More specifically, the server device104 may generate a recommended multi-modal route that includes a firstpublic transit stop one mile from the user's starting location and asecond public transit stop one miles from the user's destinationlocation. The recommended multi-modal route may include a ride servicefrom the starting location to the first public transit stop and anotherride service from the second public transit stop to the destinationlocation. In another example, the recommended multi-modal route mayinclude walking directions from the starting location to the firstpublic transit stop or from the second public transit stop to thedestination location.

By communicating with the ride service providers, the server device 104may identify a ride service provider and/or ride service type thatminimizes cost and/or wait time. When the user indicates a preferredride service provider or ride service type, the server device 104 mayretrieve ride service data from the preferred ride service provider andinclude the preferred ride service provider in the route. The serverdevice 104 may then generate one or several recommended multi-modalroutes and provide the recommended routes to the mapping application 128for the user to select one of the recommended routes and beginnavigating to the destination location.

FIG. 6 illustrates a flow diagram of an example method 800 forgenerating recommended multi-modal routes from a starting location to adestination location. The method can be implemented in a set ofinstructions stored on a computer-readable memory and executable one ormore processors of the server device 104. In other embodiments, themethod can be implemented by an application executable on the clientcomputing device 102, or a combination of the server device 104 and theclient computing device 102.

At block 802, a request for travel directions is received that includesa starting location and a destination location. The request for traveldirections may be received from a mapping application 128 executing on auser's client computing device 102. The user may provide a destinationlocation by for example selecting a search result in response to ageographic search query, entering a destination location,touch-selecting a destination location on a map display, or in any othersuitable manner. The starting location may be the user's currentlocation or another location provided by the user.

At block 804, the mapping application 128 may also provide a request toreceive the travel directions for a recommended mode of transportation.The recommended mode of transportation may include multiple modes oftransportation. Additionally, in response to a request for traveldirections using a recommended mode of transportation, the server device104 may provide multiple routes to the destination location, eachinvolving one or more modes of transportation for the user to choosefrom. When requesting travel directions using a recommended mode oftransportation, the mapping application 128 may provide user preferencesfor the recommended routes, such as “Avoid highways,” “Utilize publictransit,” “Avoid walking directions at night,” “Lowest cost,” “Shortestduration,” a preferred ride service provider and/or preferred rideservice type (e.g., a carpooling ride service), or any other suitableuser preferences.

In response to receiving the request for travel directions using arecommended mode of transportation, the server device 104 may identifyseveral routes from the starting location to the destination location,each involving one or more modes of transportation (block 806). In someembodiments, a route may include a first segment using a ride servicemode of transportation and a second segment using another mode oftransportation, such as walking, driving, biking, public transit, etc.For example, the server device 104 may identify a first route whichincludes driving from the starting location to the destination locationor ordering a ride service. The server device 104 may identify a secondroute which includes walking to a train station, taking a train from afirst train stop to a second train stop, and ordering a ride servicefrom the second stop to the destination location. Moreover, the serverdevice 104 may identify a third route which includes biking from thestarting location to a bus station, taking a bus from a first bus stopto a second bus stop, walking from the second bus stop to a trainstation, taking a train from a first train stop to a second train stop,and walking to the destination location. In other embodiments, themapping application 128 generates the travel directions using cached mapdata stored in a local memory of the client computing device 102, orgenerates travel directions using cached map data for segments of theroute that do not include a ride service.

In some embodiments, identified routes may include a particular rideservice provider and/or ride service type. For example, some rideservice providers may include a shuttle ride service type and a routemay include taking a train to a stop near a shuttle pick-up location andthen taking the ride service from the shuttle pick-up location to ashuttle stop walking distance from the destination location. In thismanner, the user may save time and reduce costs when the shuttle pick-uplocation can be timed with the train stop.

At block 808, each of the identified routes are ranked or scoredaccording to an optimization technique. For example, the identifiedroutes may be ranked or scored according to one or several factors, suchas distance, duration, cost, user data including user preferences, etc.For example, the identified routes may be ranked to minimize an overalltime of travel to the destination location. In another example, theidentified routes may be ranked to minimize an overall price oftravelling to the destination location.

In yet another example, each identified route may receive a distancescore, a duration score, a cost score, a user preferences score, or anyother suitable score, and the scores may be weighted, aggregated, orcombined in any suitable manner to generate an overall score for eachroute. The routes may then be ranked in order of their respective scoresto minimize cost, time, and/or distance. In some embodiments, routesthat do not meet the user preferences may be filtered out or may receivea score of zero. In this manner, the recommended routes and/or the rideservice provider/type of ride service may be ranked/selected in view ofuser data. For example, if the user indicates he would not like to walkat night, any routes that include a walking segment after a thresholdtime period may be filtered out or ranked at the bottom. The cost may bedetermined based on the cost for using a particular public transitsystem, or the cost for using a particular ride service provider and/orride service type. For example, the server device 104 may invoke one orseveral ride sharing APIs 208 to determine price estimates for using aparticular ride service provider and/or ride service type for a segmentof a route.

In addition to ranking the identified routes, the server device 104 mayrank candidate rides, where each candidate ride corresponds to aparticular ride service provider and ride service type. The candidaterides may be ranked or scored according to one or several factors, suchas distance, duration, cost, user data including user preferences, etc.For example, the candidate rides may be ranked to minimize the wait timefor the driver to arrive at the pick-up location. In another example,the candidate rides may be ranked to minimize an overall price oftravelling to the destination location. The server device 104 mayseparately rank the candidate rides according to wait time, price, orany other suitable category. In some embodiments, the candidate ridesmay also be ranked according to user feedback data for the ride serviceproviders. The user feedback data may include data indicate of pastratings or reviews of the ride service providers by riders.

Then at block 810, the server device 104 provides a set of routes or alisting of rides ranked above a threshold ranking (e.g., the top threehighest ranking routes) as recommended routes or rides to the mappingapplication 128 for the user to choose from. For example, indications ofeach of the top three highest ranking routes may be provided in a regionof the map display (e.g., as a series of icons representing the modes oftransportation for segments of the route) and the user may choose one ofthe routes by touch-selecting an indication of a recommended route. Inother embodiments, the server device 104 selects one route (e.g., thehighest ranking route) and provides the selected route to the mappingapplication 128. In an exemplary scenario, the mapping application 128displays three routes, where a first route includes ordering a taxi rideservice provided by Rider from the starting location (e.g., the user'scurrent location) to a train station, taking a train from a first trainstop to a second train stop, and walking to the destination location. Asecond route includes walking to a shuttle pick-up location for ashuttle ride service provided by DriverCo, taking the shuttle rideservice to a second shuttle stop/pick-up location, and walking to thedestination location. A third route includes walking to a bus station,taking a bus from a first bus stop to a second bus stop, walking to atrain station, taking a train from a first train stop to a second trainstop, and ordering a carpooling ride service provided by Rider from thesecond train stop to the destination location.

When the user selects one of the recommended multi-modal routes whichinclude a segment covered by a ride service or selects a route using theride service mode of transportation, the mapping application 128 mayinvoke one or several ride service APIs 208 to communicate with severalride service providers. For example, a route may include taking a trainfrom a first train stop to a second train stop, and ordering a rideservice from the second stop to the destination location. In thisexample, the second stop may be the pick-up location for the rideservice and the destination location may be the drop-off location. Themapping application 128 may identify an estimated time in which the userwill arrive at the second train stop and thus the pick-up location.Accordingly, the mapping application 128 may request the ride to beginat the estimated time at the pick-up location or within a threshold timeperiod of the estimated time (e.g., within five minutes, ten minutes,etc.).

Also when the user selects one of the recommended multi-modal routes,the mapping application 128 presents a visualization of the route on themap display. For example, the visualization may include indications ofthe starting and destination locations, such as pins at the twolocations. The visualization may also include an indication of the routefrom the starting location to the destination location. For example,each of the streets, roads, highways, and maneuvers along the route maybe highlighted or indicated in any suitable manner. Also, each segmentof the route may include an indication of a respective mode oftransportation for the corresponding segment. For example, a firstsegment of the route may be denoted with dashed lines indicating walkingdirections for the first segment and a second segment of the route maybe denoted with a solid line indicating driving directions for thesecond segment.

In some embodiments, when the user selects a recommended multi-modalroute that includes a particular ride service provider and ride servicetype, the mapping application 128 may only present ride service data forthe selected ride service provider and ride service type. For example,when the user or the server device 104 selects a particular ride fromseveral candidate rides, the mapping application 128 may request rideservice data for the selected ride. In other embodiments, the mappingapplication 128 presents ride service data for each ride serviceprovider and ride service type to allow the user another opportunity toselect the ride service provider and ride service type.

FIG. 7 illustrates a flow diagram of an example method 900 for providingride services within a mapping application without directing the user toa separate ride service application. The method can be implemented in aset of instructions stored on a computer-readable memory and executableone or more processors of the client computing device 102. For example,the method can be implemented by an application stored on the clientcomputing device, such as the mapping application 128. In otherembodiments, the method can be implemented by the server device 104, ora combination of the client computing device 102 and the server device104.

At block 902, a route from a starting location to a destination locationis selected that includes at least a segment covered by a ride service.For example, the mapping application 128 may present several recommendedmulti-modal routes to the destination location and a user may choose oneof the recommended multi-modal routes by for example, touch-selecting anindication of the route, as described above with reference to FIG. 6 .In another example, the mapping application 128 may include a usercontrol for requesting travel directions to a selected destinationlocation. When the user requests travel directions via the user control,the mapping application 128 may provide user controls for selecting amode of transportation including a ride service mode.

When the ride service mode is selected, the mapping application 128 mayinvoke one or several ride service APIs 208 to communicate withrespective ride service providers for requesting rider services (block904). The mapping application 128 may provide a ride service requestusing each ride service API 208 along with a current location of theuser and a destination location, for example. The ride service API 208may then forward the ride service request to a corresponding rideservice application 126 or a ride service provider server 106, which mayin turn provide ride service information to the ride service API 208which is then forwarded to the mapping application 128 (block 906). Rideservice information may include types of ride services available, anestimated time for arrival of a ride through each type of ride service,an estimated price for each type of ride service, an estimation of thevehicles/drivers in the area, etc.

In addition to providing ride service information, the ride serviceprovider, via the ride service API 208, may provide style orvisualization information and custom layouts for presenting the rideservice information on the map display, for presenting other elements onthe map display, or for rendering any suitable visualization of the rideon the map display. This is described in more detail below withreference to FIGS. 9-13B. More specifically, the mapping application 128may retain control over some components on the map display whileallowing the ride service provider to customize the layout for othercomponents on the map display. For example, the mapping application 128may retain control over the base map included within the map display,but may allow the ride service provider to customize the search baroverlaying the base map at the top of the map display or the rectangularlayout overlaying the base map at the bottom of the map display. Thecustomized layouts do not need to be at the top or bottom of the mapdisplay and the ride service provider may also customize the location ofthe layouts within the map display. In addition to customizing layouts,the ride service provider may provide style information to adjust thestyle of elements on the map display controlled by the mappingapplication 128. For example, the ride service provider may providestyle or visualization information for rendering elements in the basemap, such as a background color for the base map, colors for highwaysroads, and streets, a font size, color, and type for map labels, a colorscheme, line thickness, or stoke type for the base map, a graphic suchas a vehicle icon representing a current location of a vehicle on themap, an icon representing the user's current location, a pick-uplocation icon representing the pick-up location, a drop-off locationicon representing the drop-off location, a current orientation iconrepresenting the current orientation of the client computing device, orany other visual attributes.

In any event, the mapping application 128 may then present the rideservice information on the map display (block 908), similar to thedisplay as shown in FIG. 9 . More specifically, for each ride serviceprovider, the mapping application 128 may present an indication of theride service provider, such as the name and logo for the ride serviceprovider. The mapping application 128 may also present indications ofthe ride service types provided by the ride service provider (e.g., acarpooling ride service, a taxi ride service, a limo ride service, ashuttle ride service, an extra-large vehicle service, etc.) as well asprice and wait time estimates for each ride service type. When themapping application 128 presents ride service information for multipleride service providers on the map display, the user may select one ofthe ride service providers via a user control such as touch-selectingthe indication of the ride service provider. In response to selectingthe ride service provider, the mapping application 128 may present theindications of the ride service types provided by the selected rideservice provider as well as the price and wait time estimates for eachride service type. The user may also select a ride service type via auser control such as touch-selecting the indication of the ride servicetype.

Additionally, the mapping application 128 may present the ride serviceinformation for each of the ride service providers with the respectivestyle or visualization information and custom layouts from thecorresponding ride service provider. Accordingly, the mappingapplication 128 may re-render the map display in according with thereceived style or visualization information. In some embodiments, whenthe user selects one of the candidate ride service providers, themapping application 128 adjusts the map display to include the styleinformation and custom layouts for the selected ride service provider.Then when the user selects another ride service provider, the mappingapplication 128 changes the map display to include the style informationand custom layouts for the other ride service provider. For example,Rider may provide a pink vehicle icon, a dark blue background color forthe base map, a triangular icon for representing the user's currentlocation, and a customized layout for selecting the ride service type,where the user can provide a swipe gesture to view a new ride servicetype on the map display. The customized layout may also include icons toselect between an economy or premium ride, to split the fare betweenseveral passengers on the ride, or to order a ride for a group, forexample.

At block 910, the mapping application 128 receives a selection of a rideservice provider and a ride service type. For example, the user mayselect a carpooling service named RiderPool from Rider bytouch-selecting a user control, such as the RiderPool icon or a “SelectRiderPool” button. As a result, the mapping application 128 presents apick-up request display that includes a user control for selecting apick-up location, similar to the display as shown in FIG. 12A. The usercontrol may be a pin or other icon which is placed at a default pick-uplocation on the map display. For example, the default pick-up locationmay be the user's current location or may be a recommended pick-uplocation.

The user may then adjust the pick-up location by for example, draggingthe user control to another location on the map display. In someembodiments, the pickup-request display includes an indication of therecommended pick-up location which remains on the pickup-request displaywhen the user moves the pin to another location, so that the user canlater select the recommended pick-up location. The indication of therecommended pick-up location may include an indication of the distancefrom the user's current location to the recommended pick-up location andindications of the time and cost savings associated with the recommendedpick-up location. For example, in an area with several one-way streets,the mapping application 128 may recommend a pick-up location at a streetthat allows the driver to travel in the direction of the destinationlocation, so that the driver does not need to make unnecessary turnsafter picking up the user. In another example, the recommended pick-uplocation may be determined based on traffic to avoid streets with heavytraffic in order to minimize cost. The mapping application 128 mayidentify a recommended pick-up location within a walking distance orthreshold distance of the user's current location (e.g., within 500 or1000 feet) to minimize the time and/or cost of the ride.

Additionally, the pick-up request display may include a preview of athree-dimensional street level view of the area around the pick-uplocation in a portion of the pick-up request display, so that the usermay easily find the driver at the pick-up location. The preview mayinclude a selectable user control, such that when selected, the pick-uprequest display presents a full screen view of the three-dimensionalpanoramic street level view of the area around the pick-up location. Insome embodiments, the pick-up request display may overlay the streetlevel view at a fixed predefined location on the base map, such as alocation corresponding to the pick-up location. Moreover, the pick-uprequest display includes the style information and custom layouts fromthe ride service provider. For example, the ride service provider mayprovide a user control for confirming the pick-up location, such as aconfirm button or other suitable icon and may indicate the position ofthe user control within the pick-up request display (e.g., below thebase map at the bottom of the pick-up request display, above the basemap at the top of the pick-up request display, etc.). In someembodiments, the pick-up request display or any other suitable displaymay also include a preview of a three-dimensional street level view ofthe area around the drop-off location. The preview may include aselectable user control, such that when selected, the correspondingdisplay presents a full screen view of the three-dimensional panoramicstreet level view of the area around the drop-off location. In someembodiments, the corresponding display may overlay the street level viewat a fixed predefined location on the base map, such as a locationcorresponding to the drop-off location.

Accordingly, the mapping application 128 identifies the pick-up locationfor the ride as the position of the user control for selecting a pick-uplocation when the confirmation user control is selected. At block 912,the mapping application 128 invokes the ride service API 208 to providea pick-up request to the ride service provider along with the selectedride service type and pick-up location. In some embodiments, the mappingapplication 128 also provides a rider identifier such as user logininformation for logging the user into a user profile maintained by theride service provider. For example, the user profile may include paymentmethods for the user, the name of the user, an email address of theuser, a phone number of the user, a picture of the user for the driverto identify the user, a rating of the user, a ride ID for a ridecurrently in progress or ride the user is requesting, or any othersuitable user profile information. The ride service API 208 may thenforward the ride service request to a corresponding ride serviceapplication 126 or a ride service provider server 106, which may in turnprovide ride confirmation information to the ride service API 208 whichis then forwarded to the mapping application 128 (block 914).

The ride confirmation information may include a ride ID for retrievingstatus information for the ride, driver identification information forthe selected driver (e.g., the name of the driver, the vehicle make,model, and color, a license plate number, etc.), an updated priceestimate, an updated wait time, and an updated ride duration. The rideservice provider, via the ride service API 208, may also provide styleinformation and custom layouts for presenting the ride confirmationinformation on the map display or for presenting other elements on themap display.

At block 916, the mapping application 128 presents the ride confirmationinformation on the map display, similar to the display as shown in FIG.13A. More specifically, the mapping application 128 may present anindication of an estimated wait time for the driver to arrive at thepick-up location (e.g., “Driver arriving in 1 minute”), an indication ofthe user's current location, an indication of the pick-up location, andan indication of the driver's location on the base map. The mappingapplication 128 may also present a user control for contacting thedriver. Additionally, the mapping application 128 may present the rideconfirmation information for the ride service provider with the receivedstyle information and custom layouts.

At block 918, the mapping application 128 periodically transmits statusrequests to the ride service provider, by for example invoking the rideservice API 208 and providing the ride ID. Status requests may betransmitted every five seconds, every ten seconds, every 30 seconds,every minute, etc. (block 922). The ride service provider may thenreturn a status, such as waiting for the driver to accept the ride,waiting for the driver to arrive at the pick-up location, ride inprogress, ride completed, or any other suitable status. When the statusis waiting for the driver to arrive at the pick-up location or ride inprogress, the ride service provider may also return the location of thedriver. The mapping application 128 then presents a status indicatorand/or the location of the driver on the map display (block 920). Forexample, when the status is waiting for the driver to accept the ride,the map display may include a banner indicating that a driver has notaccepted the ride. When the status is waiting for the driver to arriveat the pick-up location, the map display may include a banner indicatingthe estimated wait time for the driver to arrive at the pick-up locationand an indication of the driver's location on the base map, such as avehicle icon at the driver's location. Furthermore, when the status isride in progress, the map display may include an indication of thedriver's location on the base map. The mapping application 128 maycontinue to transmit status requests until the status is ride completed(block 924).

In some scenarios, a user may transition from the ride service portionof the mapping application 128 to map views of other geographic areas,to search for points of interest or other locations, or to perform anyother mapping functions while ordering the ride service or on the ride.When the user transitions to other mapping functionality, the mappingapplication 128 may continue to receive status information regarding thestatus of the ride from the ride service provider. In some embodiments,the mapping application 128 presents a banner overlaying the mapdisplay, where the banner indicates that status of the ride. Forexample, the banner may state, “Ride in progress. 10 minutes away.” Thebanner may include a user control, which when selected transitions themapping application 128 back to the ride service portion to view detailsregarding the ride, change destination locations, cancel the ride, etc.

FIG. 8 illustrates a flow diagram of an example method 1000 forpresenting ride status information when the user transitions to othermapping functionality. The method can be implemented in a set ofinstructions stored on a computer-readable memory and executable one ormore processors of the client computing device 102. For example, themethod can be implemented by an application stored on the clientcomputing device, such as the mapping application 128. In otherembodiments, the method can be implemented by the server device 104, ora combination of the client computing device 102 and the server device104.

At block 1002, the mapping application 128 presents a status indicatoror location of a driver for a requested ride to a destination locationon the map display. The status may be waiting for the driver to acceptthe ride, waiting for the driver to arrive at the pick-up location, ridein progress, ride completed, or any other suitable status. Then at block1004, the mapping application 128 receives a request for additional mapdata utilizing mapping functionality different from the ride serviceportion. For example, the request may be a geographic search query, arequest to display a geographic area, or a request for travel directionsto another destination location. In any event, the mapping application128 presents the requested map data in the map display with a ridestatus indicator, such as a banner overlaying the map display thatbanner indicates that status of the ride (block 1006). The banner mayinclude a user control, which when selected transitions the mappingapplication 128 back to the ride service portion to view detailsregarding the ride, change destination locations, cancel the ride, etc.In response to receiving a selection of the user control (block 1008),the mapping application 128 determines whether the ride has beencompleted (block 1010). If the ride has not been completed, the mappingapplication 128 transitions back to the ride service portion (block1002).

FIGS. 9-13B illustrate example map displays 1400-1800B for providingride services via a mapping application 128, such as ride requestdisplays (FIGS. 9, 11A, 11B), pick-up request displays (FIGS. 10,12A-C), and wait for ride displays (FIGS. 13A, 13B). Each of the mapdisplays may be presented by the mapping application 128 and may includeride service data from one or several ride service providers obtained byinvoking one or several ride service APIs. Still further, each of themap displays may include a base map, such as the base map 1440 as shownin FIG. 9 as well as customized layout components overlaying the basemap and provided by ride service providers, such as the layoutcomponents 1602, 1608 as shown in FIG. 11A. Additionally, elements inthe base maps may be stylized by the ride service providers. Forexample, a ride service provider may provide style information forelements included in the base map, such as a background color for thebase map, colors for highways roads, and streets, a font size, color,and type for map labels, an icon representing an vehicle on the map, anicon representing the user's current location, a pin representing thedestination location, etc.

FIG. 9 illustrates an exemplary display 1400 for selecting a rideservice provider in a mapping application 128. The display 1400 mayappear on a portable device such as the client computing device 102 asshown in FIG. 1 . The display 1400 may include a user control 1402 forentering a starting location, a user control 1404 for entering adestination location, a user control 1406 for selecting a mode oftransportation for traveling from the starting location to thedestination location, and a base map 1440 centered 1408 around theuser's current location. In some embodiments, the default startinglocation 1402 may be the user's current location. When the user selectsa ride services mode of transportation 1442 or selects a recommendedmode of transportation (not shown) having multi-modal travel directionsthat include a segment covered by a ride service, the display 1400 mayinclude a customized layout 1410 overlaying the base map 1440 thatpresents indications of one or several ride service providers 1420,1422.

In the example display 1400, the ride service providers include Rider1420 and DriverCo 1422. Each of the ride service providers may providecustomized layouts, and the display 1400 may present the layoutcustomized by a selected ride service provider. For example, the usermay select Rider 1420 by touch-selecting the indication of Rider ondisplay 1400, and the display 1400 may present a layout 1410 customizedby Rider. The customized layout 1410 includes an indication of a type ofride service 1430 (RiderPool) and selectable options for the RiderPoolservice, such as economy or premium, split the fare amongst thepassengers, request RiderPool for a large group, etc. In the customizedlayout 1410, the user may perform a swipe gesture to view other types ofride services provided by Rider. However, this is merely one examplelayout for illustration purposes only. In other customized layouts, thedisplay 1400 may include indications of each type of ride service 1430at the same time, and the user may choose a type of ride service bytouch-selecting the corresponding indication, for example. In any event,the customized layout 1410 also includes a user control 1432 to selectthe RiderPool service provided by Rider.

FIG. 10 illustrates an exemplary display 1500 for selecting a pick-uplocation in a mapping application 128. The display 1500 may appear on aportable device such as the client computing device 102 as shown in FIG.1 . As in FIG. 9 , the display 1500 may include a base map 1502 centeredaround the user's current location 1520. The display may also include auser control 1522 such as a pin for selecting the pick-up location. Insome embodiments, the default pick-up location may be the user's currentlocation 1520 and the user may be able to drag the pin to select anotherlocation for the pick-up location. The display 1500 also includesindications of recommended pick-up locations 1504 and 1506 shown ascircles. A preview of a three-dimensional street level view 1508 of thearea around a pick-up location may be provided for one of therecommended pick-up locations, so that the user may easily find thedriver at the pick-up location. The preview may include a selectableuser control, such that when selected, the pick-up request displaypresents a full screen view of the three-dimensional street level viewof the area around the pick-up location. Additionally, the display 1500may include indications of the number of available vehicles 1510employed by the ride service provider. While the locations of thevehicles on the map display may not be an accurate representation of thelocations of the vehicles employed by the ride service provider, thenumber of vehicles on the map display may be used to show the user anapproximation of the amount of vehicles in the area.

In some embodiments, the mapping application 128 identifies a landmarkthat corresponds to the pick-up location, or that is within a thresholddistance of the pick-up location (e.g., 100 feet). The mappingapplication 128 then can include street-level imagery for the identifiedlandmark in the three-dimensional street level view 1508. The mappingapplication 128 additionally or alternatively can provide via theinterface an indication of the landmark, such as “Pickup in front ofDisney Store.” For example, the mapping application 128 can invoke theAPI exposed by the ride service provider to obtain geographiccoordinates or the street address of the pick-up location (e.g., “123Elm St.”) and identify an appropriate landmark corresponding to thesecoordinates or this address. To this end, the mapping application 128can transmit the coordinates and/or the street address to a map dataserver or, in some cases, rely on cached map data and street-levelimagery. The map data server or, when cached data is used, the mappingapplication 128, can identify a landmark based on such properties asprominence (e.g., relative size of a landmark relative to other objectsin the vicinity of the landmark, or difference in color between thelandmark and nearby objects), visibility (e.g., availability of a directline of sight between the pick-up location the landmark), popularity(e.g., amount of user-generated content such as photographs, reviews,etc. related to the landmark), or other suitable signals. Further, themap data server or the mapping application 128 in some embodiments canselect the street-level imagery for the landmark location so as to facethe landmark, regardless of the expected orientation of the user at thepick-up location relative to the landmark, for inclusion in the view1508. For example, the map data server or the mapping application 128can provide an image of a monument and generate the notification “pickup at 123 Elm St., across the street from the monument.”

FIGS. 11A and 11B illustrate example ride request displays 1600A, 1600Bin a mapping application 128 that include layout components which arecustomized by a ride service provider. The displays 1600A, 1600B mayappear on a portable device such as the client computing device 102 asshown in FIG. 1 . As mentioned above, ride service providers may providecustomized layouts and style information to present in a mappingapplication 128. The ride request display 1600A includes a base map1604, a custom location search component 1602 overlaying the base map1604, and a custom third party layout component overlaying the base map1608. The ride service providers may customize these components 1602,1608 in any suitable manner and may adjust the position of thecomponents 1602, 1608 within the ride request display 1600A. Forexample, Rider may request that the location search component 1602 ispresented at the bottom of the ride request display 1600A. In oneexample, the location search component 1602 includes user controls forproviding a starting location, a destination location, and a mode oftransportation for providing travel directions to the destinationlocation. The custom third party layout component 1608 includesselectable indications of each of the ride service types provided by theride service provider as well as indications of price estimates and waittimes for each ride service type. The custom components may also includeicons, background colors, animations, or any other suitable graphicalelements. FIG. 11B illustrates example custom layout components 1602,1608 for the ride request display 1600B. In the ride request display1600B, the custom location search component 1602 includes user controlsfor providing a starting location and a destination location. The customthird party layout component 1608 includes circular, selectableindications 1610 a-e of the ride service types available from the rideservice provider. The custom third party layout component 1608 alsoincludes a price estimate, estimated wait time, and payment method aswell as a user control 1612 for requesting the selected ride serviceprovider and/or ride service type.

In response to receiving a selection of the user control 1612 forrequesting the selected ride service provider and/or ride service type,the mapping application 128 presents a pick-up request display 1700A-C,as shown in FIGS. 12A-12C. The pick-up request displays 1700A-C mayappear on a portable device such as the client computing device 102 asshown in FIG. 1 . The pick-up request display 1700A includes a base map1702, a pick-up location layout component 1704, and a pick-upconfirmation layout component 1706. In some embodiments, the pick-upconfirmation layout component 1706 is customizable by the selected rideservice provider. The pick-up request display 1700A also includes anindication of the user's current location 1710, and a user control 1712such as a pin for selecting the pick-up location. In some embodiments,the default pick-up location may be the user's current location 1710 andthe user may be able to drag the pin to select another location for thepick-up location. The pick-up request display 1700A also includes apreview of a three-dimensional street level view 1708 of the area aroundthe selected pick-up location or around a recommended pick-up location,so that the user may easily find the driver at the pick-up location. Thepreview may include a selectable user control, such that when selected,the pick-up request display 1700A presents a full screen view of thethree-dimensional street level view of the area around the pick-uplocation.

FIG. 12B illustrates another example pick-up request display 1700B whenthe user 1710 is located at an airport, and there are severalrecommended pick-up locations. The recommended pick-up locations areshown in a location list 1714 as available pick-up areas. The user mayselect one of these pick-up locations and confirm the selection usingthe pick-up confirmation layout component 1706. FIG. 12C illustrates yetanother example pick-up request display 1700C when the user 1710 islocated at an airport. In addition to the location list 1714, thepick-up request display 1700C includes a user control 1716 for selectingone of several levels where the user may be picked up. For example, thelocation list 1714 may include a first set of recommended pick-uplocations for a first level of a building, and a second set ofrecommended pick-up locations for a second level of a building.

In response to receiving a selection of the user control 1706 forconfirming the pick-up location, the mapping application 128 presents await for ride display 1800A, 1800B, as shown in FIGS. 13A and 13B. Thewait for ride displays 1800A, 1800B may appear on a portable device suchas the client computing device 102 as shown in FIG. 1 . The wait forride display 1800A may include an indication of the user's currentlocation 1802, an indication of the vehicle 1804 picking up the user,and an indication of the pick-up location. The wait for ride display1800A may also include an arrival layout component 1808 that includes anindication of an estimated wait time for the driver to arrive at theselected pick-up location. Additionally, the wait for ride display 1800Aincludes a contact driver layout component 1810 with a user control forcontacting the driver. In some embodiments, the contact driver layoutcomponent 1810 is customizable by the selected ride service provider.Also in some embodiments, the driver may be contacted via a SMSapplication or a chat application.

FIG. 13B illustrates another wait for ride display 1800B presented whenthe user 1802 is located at an airport. The wait for ride display 1800Bincludes an arrival layout component 1808 as well as additionalinstructions layout component 1812 for providing detailed walkingdirection to the pick-up location. As in FIG. 12C, the wait for ridedisplay 1800B includes a user control 1814 for selecting one of severallevels where the user may be picked up.

ADDITIONAL CONSIDERATIONS

The following additional considerations apply to the foregoingdiscussion. Throughout this specification, plural instances mayimplement components, operations, or structures described as a singleinstance. Although individual operations of one or more methods areillustrated and described as separate operations, one or more of theindividual operations may be performed concurrently, and nothingrequires that the operations be performed in the order illustrated.Structures and functionality presented as separate components in exampleconfigurations may be implemented as a combined structure or component.Similarly, structures and functionality presented as a single componentmay be implemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter of the present disclosure.

Additionally, certain embodiments are described herein as includinglogic or a number of components, modules, or mechanisms. Modules mayconstitute either software modules (e.g., code stored on amachine-readable medium) or hardware modules. A hardware module istangible unit capable of performing certain operations and may beconfigured or arranged in a certain manner. In example embodiments, oneor more computer systems (e.g., a standalone, client or server computersystem) or one or more hardware modules of a computer system (e.g., aprocessor or a group of processors) may be configured by software (e.g.,an application or application portion) as a hardware module thatoperates to perform certain operations as described herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an application-specific integrated circuit (ASIC)) toperform certain operations. A hardware module may also compriseprogrammable logic or circuitry (e.g., as encompassed within ageneral-purpose processor or other programmable processor) that istemporarily configured by software to perform certain operations. Itwill be appreciated that the decision to implement a hardware modulemechanically, in dedicated and permanently configured circuitry, or intemporarily configured circuitry (e.g., configured by software) may bedriven by cost and time considerations.

Accordingly, the term hardware should be understood to encompass atangible entity, be that an entity that is physically constructed,permanently configured (e.g., hardwired), or temporarily configured(e.g., programmed) to operate in a certain manner or to perform certainoperations described herein. As used herein “hardware-implementedmodule” refers to a hardware module. Considering embodiments in whichhardware modules are temporarily configured (e.g., programmed), each ofthe hardware modules need not be configured or instantiated at any oneinstance in time. For example, where the hardware modules comprise ageneral-purpose processor configured using software, the general-purposeprocessor may be configured as respective different hardware modules atdifferent times. Software may accordingly configured on a processor, forexample, to constitute a particular hardware module at one instance oftime and to constitute a different hardware module at a differentinstance of time.

Hardware modules can provide information to, and receive informationfrom, other hardware. Accordingly, the described hardware modules may beregarded as being communicatively coupled. Where multiple of suchhardware modules exist contemporaneously, communications may be achievedthrough signal transmission (e.g., over appropriate circuits and buses)that connect the hardware modules. In embodiments in which multiplehardware modules are configured or instantiated at different times,communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and can operate on a resource (e.g., a collection ofinformation).

The methods 500, 800, 900, and 1000 may include one or more functionblocks, modules, individual functions or routines in the form oftangible computer-executable instructions that are stored in anon-transitory computer-readable storage medium and executed using aprocessor of a computing device (e.g., a server, a personal computer, asmart phone, a tablet computer, a smart watch, a mobile computingdevice, or other personal computing device, as described herein). Themethods 500, 800, 900, and 1000 may be included as part of any backendserver (e.g., a map data server, a navigation server, or any other typeof server computing device, as described herein), portable devicemodules of the example environment, for example, or as part of a modulethat is external to such an environment. Though the figures may bedescribed with reference to the other figures for ease of explanation,the methods 500, 800, 900, and 1000 can be utilized with other objectsand user interfaces. Furthermore, although the explanation abovedescribes steps of the methods 500, 800, 900, and 1000 being performedby specific devices (such as a client computing device 102, and a serverdevice 104), this is done for illustration purposes only.

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or more processors orprocessor-implemented hardware modules. The performance of certain ofthe operations may be distributed among the one or more processors, notonly residing within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as anSaaS. For example, as indicated above, at least some of the operationsmay be performed by a group of computers (as examples of machinesincluding processors), these operations being accessible via a network(e.g., the Internet) and via one or more appropriate interfaces (e.g.,APIs).

Still further, the figures depict some embodiments of the exampleenvironment for purposes of illustration only. One skilled in the artwill readily recognize from the following discussion that alternativeembodiments of the structures and methods illustrated herein may beemployed without departing from the principles described herein.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs fororienting a user within a map display through the disclosed principlesherein. Thus, while particular embodiments and applications have beenillustrated and described, it is to be understood that the disclosedembodiments are not limited to the precise construction and componentsdisclosed herein. Various modifications, changes and variations, whichwill be apparent to those skilled in the art, may be made in thearrangement, operation and details of the method and apparatus disclosedherein without departing from the spirit and scope defined in theappended claims.

What is claimed:
 1. A method in a computing device for providing travel directions on a digital map, the method comprising: presenting, by one or more processors executing a mapping application, a map display that includes a geographic area surrounding a user's current location; receiving, at the one or more processors, a geographic search query from the user; presenting, by the one or more processors via the mapping application, a search result in response to the geographic search query; presenting, by the one or more processors via the mapping application, a user control for selecting a mode of transportation from a plurality of modes of transportation; receiving, at the one or more processors, a selection of a ride service mode of transportation via the user control; and presenting, by the one or more processors via the mapping application, (i) a set of navigation directions for traveling from the user's current location to a location indicated in the search result, (ii) one or more indications of ride service providers, (iii) one or more types of ride services from the one or more ride service providers, and (iv) one or more wait times for each type of ride service.
 2. The method of claim 1, further comprising: presenting, by the one or more processors via the mapping application, a user control for selecting one of the one or more types of ride services.
 3. The method of claim 1, further comprising: presenting, by the one or more processors via the mapping application, a user control for selecting a pick-up location.
 4. The method of claim 1, further comprising: in response to receiving a selection of one of the one or more types of ride services from the one or more ride service providers, receiving, by the one or more processors from the selected ride service provider, status information indicating a current status of a ride corresponding to the selected type of ride service; and presenting, by the one or more processors, a status indicator in accordance with the received status information.
 5. The method of claim 4, wherein: receiving status information includes receiving, at the mapping application from the selected ride service provider, a current location of a driver, and presenting a status indicator on the digital map includes presenting, by the one or more processors, an indication of the current location of the driver.
 6. The method of claim 4, wherein presenting a status indicator includes: presenting, by the one or more processors, an indication of an estimated wait time for a driver to arrive at a pick-up location.
 7. The method of claim 4, wherein the current status of the ride includes at least one of: waiting for a driver to accept the ride, waiting for the driver to arrive at the pick-up location, ride in progress, or ride completed.
 8. A computing device comprising: a user interface; one or more processors; and a non-transitory computer readable medium storing a mapping application thereon that, when executed by the one or more processors, causes the computing device to: present, via the user interface, a map display that includes a geographic area surrounding a user's current location; receive, via the user interface, a geographic search query from the user; present, via the user interface, a search result in response to the geographic search query; present, via the user interface, a user control for selecting a mode of transportation from a plurality of modes of transportation; receive a selection of a ride service mode of transportation via the user control; and present, via the user interface, (i) a set of navigation directions for traveling from the user's current location to a location indicated in the search result, (ii) one or more indications of ride service providers, (iii) one or more types of ride services from the one or more ride service providers, and (iv) one or more wait times for each type of ride service.
 9. The computing device of claim 8, wherein the mapping application further causes the computing device to: present, via the user interface, a user control for selecting one of the one or more types of ride services.
 10. The computing device of claim 8, wherein the mapping application further causes the computing device to: present, via the user interface, a user control for selecting a pick-up location.
 11. The computing device of claim 8, wherein the mapping application further causes the computing device to: in response to receiving a selection of one of the one or more types of ride services from the one or more ride service providers, receive, from the selected ride service provider, status information indicating a current status of a ride corresponding to the selected type of ride service; and present, via the user interface, a status indicator in accordance with the received status information.
 12. The computing device of claim 11, wherein: the status information includes a current location of a driver, and the status indicator includes an indication of the current location of the driver.
 13. The computing device of claim 11, wherein the status indicator includes an indication of an estimated wait time for a driver to arrive at a pick-up location.
 14. The computing device of claim 11, wherein the current status of the ride includes at least one of: waiting for a driver to accept the ride, waiting for the driver to arrive at the pick-up location, ride in progress, or ride completed.
 15. A non-transitory computer readable medium storing a mapping application thereon that, when executed by the one or more processors, causes the one or more processors to: present, via a user interface, a map display that includes a geographic area surrounding a user's current location; receive, via the user interface, a geographic search query from the user; present, via the user interface, a search result in response to the geographic search query; present, via the user interface, a user control for selecting a mode of transportation from a plurality of modes of transportation; receive a selection of a ride service mode of transportation via the user control; and present, via the user interface, (i) a set of navigation directions for traveling from the user's current location to a location indicated in the search result, (ii) one or more indications of ride service providers, (iii) one or more types of ride services from the one or more ride service providers, and (iv) one or more wait times for each type of ride service.
 16. The non-transitory computer readable medium of claim 15, wherein the mapping application further causes the one or more processors to: present, via the user interface, a user control for selecting one of the one or more types of ride services.
 17. The non-transitory computer readable medium of claim 15, wherein the mapping application further causes the one or more processors to: present, via the user interface, a user control for selecting a pick-up location.
 18. The non-transitory computer readable medium of claim 15, wherein the mapping application further causes the one or more processors to: in response to receiving a selection of one of the one or more types of ride services from the one or more ride service providers, receive, from the selected ride service provider, status information indicating a current status of a ride corresponding to the selected type of ride service; and present, via the user interface, a status indicator in accordance with the received status information.
 19. The non-transitory computer readable medium of claim 18, wherein: the status information includes a current location of a driver, and the status indicator includes an indication of the current location of the driver.
 20. The non-transitory computer readable medium of claim 18, wherein the status indicator includes an indication of an estimated wait time for a driver to arrive at a pick-up location. 